前兩天提到 dbt 將資料庫由上游至下游分成了 staging, intermediate, marts，今天來說說在各階段中模型命名時遇到的難題。

真的不要小看命名，我常常在下載遊戲後，因為平常用的名稱被別人用了，想不到名字就放棄遊玩這款遊戲（？？？

staging (ref)

stg_[source]__[entity]s.sql 這個基本上就是 staging 模型命名規則的核心，在 staging 其實通常不太會遇到甚麼問題。

我們的 source 包含 backend, ga, gcp 等等，基本上在 BigQuery 有一個原始資料的資料集，就會為其建立一個新的 source。而 entity 的部分就是依循原始資料本來的名字，除非他用的是 camelCase，會在這邊統一命名規則，不太會直接改名，staging 的部分就得盡量比照原始資料，一份原始資料對應一個 staging model，否則之後找資料不容易對應上。

有個例外是可能有多份原始資料對應一個 staging model，像是我們就蠻常遇到這種情況：

同樣定位的資料，由於 API 更新、程式邏輯有調整，將新舊版的資料分成了兩張不同的資料表，這時候或許 union 會是一個解決方法。不確定是否大家都認同這樣的作法，但我認為只要組織內統一口徑一致即可。

intermediate (ref)

int_[entity]s_[verb]s.sql 在 intermediate 中，entity 就不再多做說明，需要討論的大都是後面的 verb。

文件中舉了一些範例：pivoted, aggregated_to_user, joined, fanned_out_by_quantity, funnel_created。當時我們花了不少時間討論，仍然只針對比較常用的一些內容有共識，多數的模型還是得作為個案，一一對齊理解，包含要用哪個單字？作為非母語人士，哪個動詞最直觀能聯想到這個模型所進行的轉換，名詞還是動詞要放在前面？要不要加介係詞？

這些在母語環境中，也許不是什麼難事，但在我們團隊中，花了蠻多時間在對齊這部分的理解，為什麼會這麼重視命名呢？

在開發的時候，我們都只能先看到一整排的模型名稱，而不是它們的內容。dbt 在模型命名上，期待達到的效果是－－見名如見表。看到名稱馬上能夠知道模型裡面進行了哪些操作，當然可能沒辦法非常詳細，但至少要對於它在整個 pipeline 中上下游的位置，跟哪些模型有關都要能從名稱中看出來，因此命名的重要性就顯現出來了。

marts (ref)

在 marts 中，邏輯就跟 staging 與 intermediate 不太相同了。

首先，dbt 建議 marts 預設建成資料表(table)，會運算程式碼並將資料做實體儲存；而 staging, intermediate 預設建成 view，只會先將程式碼做儲存，留下欄位、運算邏輯等，卻不先儲存資料。

這是由於資料庫中分成儲存費用與運算費用，staging, intermediate 中的模型會被多次使用，然而資料的使用者卻不在乎這些模型中的資料，畢竟資料就還未轉換完畢，半成品是不需要做出來占用儲存費用的。

然而 marts 中的資料，很可能會被業務單位直接做使用，或者是在下游的資料分析工具中，透過簡單的篩選後進行使用，需要頻繁地取用這些資料，因此就需要將資料實體儲存於資料庫中，否則每次業務單位更新，上游龐大的原始資料都要重新運算過一遍。

從上面這邊的討論可以知道，marts 是為資料使用端做服務的，因此在架構與命名上，都需要以使用者為主，取名時以業務單位熟悉的方式命名。

除了上面這些內容，我們花了很多力氣釐清之外，還有一個問題點是英文的單複數問題。（認真？？？）

首先是可數與不可數名詞、以及複數是不規則形的詞彙。

聽說有些人會簡單暴力全部都用有沒有加 S 來做區辨，但就是覺得不太對勁。

就這樣的問題，沒想到居然要花好多時間來釐清…

接著則是複數的位置，簡單以影片相關資料來舉例：

當前平台的影片資訊，我們命名為 dim_videos，dim 為 dimension 的縮寫，通常存放一些事實，像是我們目前有的影片、習題、使用者都算。

而我們也想加入 fct_videos，fct 為 fact 的縮寫，存放歷史資料，而這邊的歷史資料並非使用者使用的歷史，而是平台影片上下架與編輯的歷史，可能影片的描述有調整、標題有更新，每次的變動我們就新增一筆紀錄。

在這兩張表之後，要如何命名使用者觀看影片的表呢？

在苦思許久之後，我們決定使用 fct_user_records_of_videos 來進行使用者觀看紀錄的命名。

回到一開始的問題：S 要加哪裡呢？

表的單位應該是整張表裡的資訊，像是許多使用者，應該就是 users。

所以許多使用者，使用了許多不同影片的各種紀錄，三個單位都要複數嗎？

還是 user_records 應該作為一個名詞，只加在 records 上？

我們最後是採取了 fct_user_records_of_videos 的命名方式，其實也不確定是否為標準答案，有蠻多討論空間。

但如我一再強調的，組織內必須要有共識，不然每次要找表動不動就差個 s 找不到實在是太慘烈了。